Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.14%. Comparing base (56223f6) to head (33dee00).

@@           Coverage Diff           @@
##             main     #680   +/-   ##
=======================================
  Coverage   55.14%   55.14%           
=======================================
  Files          15       15           
  Lines        1206     1206           
=======================================
  Hits          665      665           
  Misses        541      541           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

I'm not totally convinced myself. Rather, I am convinced that dependency groups are the proper way to define dependencies nowadays, but unsure that it is feasible to avoid specifying the build system both at the top and the bottom of pyproject.toml — which would probably be a tox shortcoming.

The latter does require more investigation, I'm sorry about that.

I'm not totally convinced myself. Rather, I am convinced that dependency groups are the proper way to define dependencies nowadays, but unsure that it is feasible to avoid specifying the build system both at the top and the bottom of pyproject.toml — which would probably be a tox shortcoming.

The latter does require more investigation, I'm sorry about that.

The dependencies in build-system are installed in isolation just for the build process. They're not made available in the test environment.

I understand this is all supposed to work automatically. From the tox documentation:

Packaging

tox builds projects in a PEP 518 compatible virtual environment and communicates with the build backend according to the interface defined in PEP 517 and PEP 660. To define package build dependencies and specify the build backend to use, create a pyproject.toml at the root of the project. For example to use hatch:

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling>=0.22", "hatch-vcs>=0.2"]

Build environments

tox uses a virtual environment for building, whose name depends on the artifact type:

• For source distributions: the package_env (default .pkg)
• For wheels: the wheel_build_env (default .pkg-<impl><version>, e.g. .pkg-cpython313)
• For sdist-wheel: uses two environments — the package_env for building the sdist, and the wheel_build_env (default .pkg-<impl><version>) for building the wheel from the extracted sdist

For pure Python projects (no C extensions), set wheel_build_env to the same value as package_env. This way the wheel is built once and reused for all tox environments:
``toml
[env_run_base]
package = "wheel"
wheel_build_env = ".pkg"

At least, I understand this should work, as it lets build handle the [build-system] automatically:

python -m build --sdist --no-isolation

I guess this doesn't work, as it requires the flit CLI:

python -m flit build --format=sdist

I will test all that more thoroughly, but need to understand what tests/test_sdist.py does. What exactly does it try to compare? With and without PEP 517 isolation? python -m build vs. python -m flit build? And why is that test important?

I understand this is all supposed to work automatically. From the tox documentation:

Packaging

tox builds projects in a PEP 518 compatible virtual environment and communicates with the build backend according to the interface defined in PEP 517 and PEP 660. To define package build dependencies and specify the build backend to use, create a pyproject.toml at the root of the project. For example to use hatch:

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling>=0.22", "hatch-vcs>=0.2"]

Build environments

tox uses a virtual environment for building, whose name depends on the artifact type:

• For source distributions: the package_env (default .pkg)
• For wheels: the wheel_build_env (default .pkg-<impl><version>, e.g. .pkg-cpython313)
• For sdist-wheel: uses two environments — the package_env for building the sdist, and the wheel_build_env (default .pkg-<impl><version>) for building the wheel from the extracted sdist

For pure Python projects (no C extensions), set wheel_build_env to the same value as package_env. This way the wheel is built once and reused for all tox environments:
``toml
[env_run_base]
package = "wheel"
wheel_build_env = ".pkg"

At least, I understand this should work, as it lets build handle the [build-system] automatically:

python -m build --sdist --no-isolation

I guess this doesn't work, as it requires the flit CLI:

python -m flit build --format=sdist

I will test all that more thoroughly, but need to understand what tests/test_sdist.py does. What exactly does it try to compare? With and without PEP 517 isolation? python -m build vs. python -m flit build? And why is that test important?

This test was contributed to the project after a failed release when setuptools was replaced with flit as the build backand, and the sdist didn't contain the expected files. I wouldn't characterize this as an important test anymore, but I have no good reason to toss it away either. I must ask, why are you so invested in making these little changes to this project?

To be honest, that's because I am fed up with the cacophony that characterizes Python development tools, at odds with the initial simplicity of the language itself. The whole ecosystem reminds of Perl ("There Is More Than One Way To Do It"). That's especially true nowadays when comparing Python to more recent languages like Go and Rust. Consistency and homogeneity, especially in the Python development tools themselves, would probably help everyone package Python software in a clean, standard and maintainable way.

Rust and Go have the advantage of hindsight, and Python had to solve problems these languages never had, and still don't have. That said, I don't see how the changes in this PR help with this at all. These changes only deal with how the wheel project itself is developed, and the requires = ["tox>=4.22"] change is the only thing here that at least marginally improves things.